Candidate fix for #1054. Surprisingly small amount of code changed in the end.

Canvas.raster and tf.shade both accept xr.DataArrays with dims[-2:] == ('y', 'x') and the direction of each of x and y coords may be increasing or decreasing. The orientation of the DataArray returned from these functions should be the same as the input, so if e.g. the input to Canvas.raster is flipped in the x-direction then so will the output be. This keeps the data and coordinates in sync. This was not previously the case, the data was flipped within datashader but the coordinates weren't.

Because the data and its coordinates are synchronised, you can plot the DataArrays in holoviews or hvplot and they are correctly rendered with increasing x and y.

Here are two examples of this working. Firstly the OP's test case of issue #1054 using a GeoTIFF obtained from https://github.com/mommermi/geotiff_sample. The land is on the southeast, the x-coords are increasing and the y-coords are decreasing:

At the top the datashader Image has y-flipped as the input data does because it just draws the image data and ignores the coordinates. Below this it is plotted directly by hvplot and also using datashader which use the coordinates correctly.

Second example to be completely explicit.

There are 4 DataArrays, one for each of the 4 x/y flipping combinations. hv.Image and shade(image) draw them all correctly as the coordinates remain correctly oriented with respect to the data regardless of if they are passed through datashader or not. At the bottom are datashader.Images that are returned from ds.Canvas.raster followed by ds.tf.shade. The images are shown in their flipped orientation as the coordinates are ignored for rendering.

One thing I have not done is consider DataArrays with dims == ('x', 'y'). These are allowed but always interpreted as dims == ('y', 'x') so strange things can result. We will need to do something about this as even some of the reproducers in issue #1054 use dims == ('x', 'y') which made them not very helpful in diagnosing the cause of the problem. I don't think we can forceably transpose them to get ('y', 'x') but we could do some checking and either raise an exception or print a warning. But we need to be careful as we cannot just look for x and y but also need to consider lat, lon, latitude and so on.

I have kept the calc_res function as it is. This returns the x and y resolutions (i.e. spacings) of the specified DataArray, but it chooses to reverse the yresolution. This annoys me a lot as it is unnecessary, but I have left it in case of external libraries that are using this function as it is considered public.